Post implementation maintenance may be the longest and the most time consuming aspect of owning software during its life cycle. While normal system lifecycle continues to shrink (at the present time it is approximately 7 years) due to the speed at which changes occur in business and technology environments, the maintenance phase still extends over the entire lifetime of the system—whatever the length of that lifetime may be. And while maintenance is important, managing changes is not restricted to the post implementation phase in the software lifecycle. A major reason attributed to project schedule slippage and cost overruns is the instability of requirements and changes to these requirements during the development phase. These changes may relate to technological and/or business issues.
During a system lifecycle, handling changes in software is inherently complex. This complexity arises because of the number of individual interacting modules and peripherals in the system, a poor understanding and availability of reliable engineering information about the system, the fact that connection semantics between modules and peripherals are not governed by physical laws, and the myth that software can be changed at will owing to the fact that its nature is non-physical. Irrespective of the complexity of changes, most issues in software maintenance relate to changes in the business environment and to managing the knowledge needed to change and control the configuration of the artifacts (i.e., executable modules). Complete documentation of the software systems is essential to conduct a proper impact analysis and to understand the effect of changes and the viability of alternatives. Lack of a clear identification of all impacted items leads to a poor estimation of the effort needed to change a system and quite often results in costly system problems.
In the software lifecycle, managing changes brought about by technological evolution is very different from, for example, managing changes brought about by software feature upgrades. One reason for this is that the capability to tackle changes in technology environments goes deep into the architectural principles of systems and whether the changes in the technology environment can be successfully mapped across the present implementation of the system.
Consequently, any software system needs a thorough analysis prior to implementation, including implementation of system upgrades. However, identification of the impact of additions, enhancements, changes and/or deletions at an early stage of the project lifecycle is often not done, or it is not done with clarity and standardization. As a result, there is no end to end identification of this impact from the change requirements to the final delivered artifact. In addition to identifying the impact, the ability to address the size and cost of the software, and the time to complete the set of impacted artifacts, is critical, yet not always properly addressed during system changes.
During system change implementations, it should be kept in mind that model based software artifacts may spread over different layers of implementation. Moreover, the control of changes in artifacts and rolling out these changes to the installed sites at the present time is mostly a manual process and can be troublesome.
Currently, the foregoing problems are addressed in conventional manual process approaches (such as quality systems and system documentation) and/or configuration management tool-based approaches to manage changes to the delivered artifacts.
Other features of the present embodiments will be apparent from the accompanying drawings and from the detailed description that follows.